User-Level Security : Authorization and Impersonation (part 3) - Security Token Authentication

3. Security Token Authentication

The custom authorization policy (or any authorization policy) is built to add claims to the security context for the request. However, this is not the only place where claims are added. When a request first arrives at the service, the security tokens included with the request are evaluated. These claims are also added to the security context.

The process of actually interpreting the token and adding the claims is left to a set of classes known as Token Authenticators. There is a separate authenticator for each type of token. Table 3 contains a list of the most commonly used token authenticators.

Because a single request can contain more than one token, it is possible that more than one authenticator will be used for the same request. Also, the data store used for authentication depends on the type of token. Windows tokens are authenticated against the Windows domain, as are username tokens, unless another provider has been specified. To change the provider for username tokens, change the userNamePasswordValidationMode attribute from Windows to MembershipProvider. This causes the ASP.NET membership provider to be used. Alternate membership providers can be specified in a single userNameAuthentication element. The following segment illustrates the attributes available to this element:

<userNameAuthentication
   cacheLogonTokenLifetime="<TimeSpan>"
   cacheLogonTokens="<Boolean>"
   customUserNamePasswordValidatorType="<String>"
   includeWindowsGroups="<Boolean>"
   maxCacheLogonTokens="<Integer>"
   membershipProviderName="<String>"
   userNamePasswordValidationMode="<Windows|MembershipProvider|Custom>" />

A number of attributes are directly related to caching the tokens. The cacheLogonTokenLifetime attribute specifies how long any individual token should be cached. The maxCacheLogonTokens attribute indicates how many tokens should be kept in the cache at one time. Caching tokens is controlled through the cacheLogonTokens attribute. If tokens are cached, the claim set generated by the token is stored so that if the token is presented again, the cache claims can be added without having to go back to the security data store.

The includeWindowsGroups attribute determines whether the Windows groups to which a user belongs should be included in the generated claim set. If this attribute is set to true, there is a potential performance implication because all the Windows groups will be expanded to ensure that all the appropriate groups are included in the claims.

The last three attributes are related to how the username token is authenticated. If the userNamePasswordValidationMode is set to MembershipProvider, the membership provider specified in the membershipProviderName attribute validates the credentials. If the userNamePasswordValidationMode is set to Custom, the password validator identified by the customUserNamePasswordValidatorType attribute authenticates the credentials.

Certificates are authenticated using the rules specified in the clientCertificate section of the service behavior. There are two components in the clientCertificatecertificate element specifies which certificate to use when secure communication with the client must be arranged. This would normally be required when a secure duplex channel is used and is not part of the authorization process. configuration. The

The second component is the authentication element. This element specifies how the certificate should be authenticated. The following segment illustrates the options that are available:

<authentication
   customCertificateValidatorType="<typeName>"
   certificateValidationMode="<validationMode>"
   includeWindowsGroups="<Boolean>"
   mapClientCertificateToWindowsAccount="<Boolean>"
   revocationMode="<NoCheck|Online|Offline>"
   trustedStoreLocation="<CurrentUser|LocalMachine>" />

Notice the includeWindowsGroups attribute. The value of this attribute determines whether groups are included in the generated claim set. This is the same function as is found in the userNameAuthentication element.

There are three types of validation modes. If certificateValidationMode is set to Custom, the type indicated by the customerCertificateValidatorType attribute validates the certificate. If the validation mode is set to ChainTrust, the client certificate is validated against the root certificate on the service’s computer. A validation mode of PeerTrust ensures that the public key portion of the certificate is in the Trusted People certificate store on the service’s computer. It is also possible to set the validation mode to ChainOrPeerTrust, which simply applies an OR to the previous two descriptions.

As part of the certificate validation, it is possible to use the trustedStoreLocation attribute to indicate where peer trust looks for the public keys. The options for this attribute are either CurrentUser or LocalMachine.

The last attribute associated with the authentication element is the revocationMode. There is a certificate revocation list, which is a list of certificates that are no longer considered to be valid. The revocationMode attribute indicates whether and when the incoming certificates should be checked against this list. If the value is set to NoCheck, no check is performed. If the value is set to Online, the certificate will be checked with every request. When set to Offline, the certificate will be verified against a cached list of revoked certificates.